The present invention relates to the field of portable tokens such as smart cards. More particularly, the present invention relates to a smart card capable of dynamically installing or de-installing one or more applications. Installation/de-installation may be done in the field through a terminal, or through an un-secure source such as the Internet.
Most consumers are familiar with credit cards, debit cards, and automatic teller machine (ATM) cards. Such cards are increasingly used to access, transfer and spend money. The back of these cards includes a magnetic strip storing encoded information about the cardholder and the account(s) accessible by the card. Terminals, including ATMs and merchant point-of-sale terminals, read the encoded information from the card and access the cardholder""s account to complete a transaction.
Besides the well-known credit and debit cards, stored value cards are becoming increasingly popular. Stored value cards are purchased or issued with a specific monetary value. When the cardholder desires to use the stored value card to purchase goods or services, the card is presented at the point of sale and the cost of the goods or services is deducted from the value of the card. The cardholder may continue to use the stored value card in this manner until all the value has been removed from the card. The card may then be discarded, or its value may be replenished. Such cards are commonly used to pay subway fares or to make long distance phone calls.
For many types of transactions, however, the current trend is away from credit/debit cards and stored value cards, and into a class of devices generally called smart cards. Rather than employing information encoded on a magnetic strip, smart cards include a microprocessor and a memory element embedded within a credit card size device. With a microprocessor, a smart card is able to interact with a greater variety of terminals across a broader range of transactions. In this broader range of transactions, the smart card is able to communicate more information regarding the cardholder, cardholder account, transaction authorization, etc.
The term xe2x80x9csmart cardxe2x80x9d is used throughout as a convenient name for a broad class of devices sometimes referred to as portable tokens. Smart cards are the most common present form of portable tokens, but as will be seen hereafter the actual physical form of the portable token, as well as the specific means by which the portable token communicates data to the outside world are not the subject of the present invention.
Smart cards have been used in various applications for some time. FIG. 1 shows an exemplary smart card 10. Roughly the size of a credit card, smart card 10 includes a microprocessor 12 with an integral memory element, and conductive contacts 13. Microprocessor 12 is typically a single wafer integrated circuit mounted on, or embedded within the otherwise plastic smart card. Conductive contacts 13 interface with a terminal to electrically transfer data between the terminal and the smart card. Other embodiments of the smart card do not include conductive contacts 13. Such xe2x80x9ccontactlessxe2x80x9d smart cards receive information via proximately coupling, such as magnetic coupling, or via remote coupling, such as radio communication.
The microprocessor 12 and conductive contacts 13 of FIG. 1, are shown in some additional detail in FIG. 2. Conductive contacts variously include power contacts, at least one input/output (I/O) port, a reset port, and a clock (clk) signal port. Microprocessor 12 comprises a central processing unit (CPU) 21 which is generically control logic including I/O circuitry 23. Terminal signals variously interface with CPU 21 through the conductive contacts 13 and I/O circuitry 23. Microprocessor 12 is associated with a memory element 20. The xe2x80x9cmemoryxe2x80x9d may be formed on the same integrated circuit as the microprocessor, or may be formed on a separate device. Generally, the memory includes Random Access Memory (RAM) 22, Read Only Memory (ROM) 24, and read/write memory, such as an Electrically Erasable Programable Read Only Memory (EEPROM) 26. However, some or all of these presently-used memory elements may be replaced by battery backed-up RAM, flash memory, or other electronic data storage media.
Operating power, a user input keypad, and a display for the smart card microprocessor are typically provided by a terminal. The term xe2x80x9cterminalxe2x80x9d broadly indicates any device exchanging information with a smart card using any type or number of data transfer means. A computer, ATM, merchant point-of-sale device, telephone, or security control device, are present examples of terminals.
A broad class of terminals nominally include a mechanism detecting the presence of a properly positioned smart card. Upon detecting the smart card, the terminal provides power to the microprocessor, and typically sends a reset (RST) signal to the smart card. The smart card uses the RST signal to reset itself, or to initiate an internal reset function. After reset, the smart card returns an answer-to-reset (ATR) signal to the terminal. The nature and protocol for the ATR signal is established by International Standards Organization (ISO) standard 7816. As established, the ATR is a multi-byte signal communicating basic information concerning the smart card to the terminal. Once such basic information is successfully recognized by the terminal, communication, i.e., data transfer, between the smart card and the terminal can be established.
Smart cards can be programmed to operate as stored value cards, credit cards, debit cards, ATM cards, calling cards, personal identity cards, critical record storage devices, etc. In these varied capacities, a smart card may, at least in theory, be designed to use a number of different application programs. In actual practice, however, an inability to readily develop and operate applications from a variety of sources has limited the type and number of applications placed on the conventional smart card. In fact, most conventional smart cards include only a single application, or at most a single type of application.
This is not surprising when one considers that from programming and implementation perspectives, a conventional first generation smart cards is little more than an embedded application. Looking at FIG. 3A, such first generation cards can be viewed as an application 30 stored in memory which runs a set of microprocessor-specific instructions on hardware resources 32. The term xe2x80x9chardware resourcesxe2x80x9d is used to generically indicate the memory and logic circuits, with their associated interfaces, used to execute microprocessor instructions but may also include I/O circuits, power circuits, and the other hardware. Given the structure shown in FIG. 3A, each application must be written in a very low level, or machine level language. This language is specific to the microprocessor on which the application is intended to run.
The first generation, embedded application programming model offers at least one significant advantagexe2x80x94programming flexibility. Microprocessors are typically able to execute a significant set of instructions. Since an embedded application is written at the machine level, the full range of the microprocessor""s instructions set may be accessed and utilized by the application.
Unfortunately, such programming flexibility comes at a high price. In order to run an existing application on a different microprocessor, it must often be completely rewritten. Debugging, updating, and testing of embedded applications are arduous. Further, machine level programming is difficult and requires a great deal of hardware specific expertise. Embedded programmers are, thus, hard to find and expensive to retain. All of these factors combine to restrict the number and quality of smart card applications. Further, the hardware specific nature of the resulting applications contributes to the incompatibility problems which characterize conventional smart card applications.
Such conventional smart cards do not employ a true operating system. Rather, a specific application written according to the microprocessor instruction set is stored in ROM and executed in accordance with commands received from a terminal. MPCOS, VisaCash, GSM, and Proton are examples of such first generation embedded applications.
Because conventional first generation smart cards store their embedded application in ROM, there is no real opportunity to significantly change or modify the application once smart cards are fielded. This presents a real problem to smart card issuers, since operating/programming errors and oversights, collectively and generically called xe2x80x9cbugs,xe2x80x9d are continually identified following release of any smart card application. Historically, severe bugs may only be remedied by physically replacing smart cards in the field with cards having an improved version of the application. Card issuers and users generally learn to live with less severe bugs.
Attempts have been made to avoid these unpleasant alternatives by utilizing the EEPROM portion of smart card memory. U.S. Pat. No. 5,542,081 allows xe2x80x9cfilter instructionsxe2x80x9d to be placed in the ROM based application which index an address in EEPROM. The EEPROM address thus allows subsequent programming steps to be grafted into the existing application stored in ROM. This additional filtering approach does create a mechanism of sorts for mitigating the effects of application bugs, but it doe not actually correct the errant application code generating the bug.
For example, assume an application as written in ROM creates a data object D by performing steps A and then C. In effect, A+C=D. After issuing smart cards with this application, the issuer identifies an error in the application in relation to the creation of data object D. The remedy for this error requires that D be created by steps A, then B, and then C, i.e., A+B+C=D. The conventional filtering approach would first create an xe2x80x9cincorrectxe2x80x9d D according to the ROM based application steps, and thereafter delete the incorrect data object D, and then re-create it using the EEPROM based application steps identified in the filtering instructions.
One can readily see that the filtering approach is very inefficient, and for more than one or two minor fixes results in a tangled mess of code. Not surprisingly, while this inefficient filtering approach to correcting a ROM based application works well enough for smart cards running a single application, it would not work for a smart card running multiple applications from different vendors.
The historic inability to securely modify or upgrade existing smart card applications in the field is just one reason why smart cards have failed to realize their full commercial potential. Many other reasons exist. Prominent among theses reasons is the absence of a true operating system (OS) supporting applications from multiple vendors.
A true operating system does not execute commands received from the outside world. Thus, in the context of a smart card, a true operating system will not (is unable to) execute commands received from a terminal. Rather, an operating system serves as a conduit and router for commands communicated from a terminal to an application stored on the smart card. Additionally, an operating system serves as a conduit through which an application utilizes the hardware resources. In other words, an operating system provides I/O functions and provides other functionality to applications running on the OS. Since first generation smart cards store only the application code, and since this code must necessarily executes commands received from the terminal, first generation smart cards do not include an operating system.
In an attempt to overcome the difficulties, limitations and expense associated with the programing of first generation smart cards, second generation smart cards incorporate an interpreter. An interpreter can be thought of as a library of commands. JAVA and BASIC are common interpreters. A set of commands is defined and identified in the interpreter, any one of which may be xe2x80x9ccalledxe2x80x9d by an application. The term xe2x80x9ccallxe2x80x9d or xe2x80x9ccallingxe2x80x9d is used throughout to broadly describe a relationship between two pieces of code in which one piece invokes the other. Commands, functions, definitions and instructions may be used by having one piece of code call another pieces of code. The foregoing pieces of code may reside within the an application or the OS.
Conceptually, an interpreter 33 can be thought of residing between application 30 and hardware resources 32, as shown in FIG. 3B. Thus, an application running on a second generation smart card gains access to the hardware resources only through the interpreter which converts a command into one or more microprocessor instructions.
The interpreter effectively provides a higher level of abstraction and a programming language reflecting this level of abstraction with which a broader class of programmers may effectively write applications. However, the definition of commands by the interpreter, which promotes programming efficiency and standardization, necessarily restricts programing flexibility, since an interpreter will never define the entire range of commands theoretically made possible by an unrestricted combination of the microprocessor instructions. Thus, by use of an interpreter, programming flexibility is traded away for programming ease and standardization. The use of an interpreter also slows program execution since commands must be converted into microprocessor instructions before execution.
Further, since conventional smart cards implement the file structure defined by ISO-7816, part 4, the use of an interpreter comes as an additional penalty to programming flexibility. That is, ISO-7816, part 4 already confines an application programmer to a certain command set used to define a standard file architecture. On top of this restriction, the interpreter further confines the programmer to another fixed set of commands. If a particular functionality is not defined by a command in the interpreter""s library, the functionality can not be implemented within an application.
For example, if some new smart card application desired the function of outputting data to a printer, this function could not be implemented if the interpreter lacked the necessary command, such as a xe2x80x9cPRINTxe2x80x9d command commonly associated with desktop computers. Such functional inabilities attributable to the interpreter are particularly exasperating where a sequence of microprocessor instructions might be designed to implement the desired xe2x80x9cnewxe2x80x9d function, but where the programmer lacks access to the microprocessor instruction set because of the obligatory presence of the interpreter.
Like the embedded application of first generation smart cards, both the application and the interpreter of second generation smart cards are stored in ROM. The process of correcting bugs is thus complicated by the possibility of fixing code in one or both of the interpreter and the application.
Even where modification or upgrading to a fielded smart card application can be accommodated in the conventional smart card, the physical process of reprogramming must be performed in a xe2x80x9ctrustedxe2x80x9d device. That is, a terminal controlled by the smart card issuer must used to reprogram the smart card application in order to ensure code integrity. This is true because conventional smart cards, in and of themselves, do not have the processing capability or sophistication to verify new programming code.
Rather, conventional smart cards merely store security keys which are exported to the trusted machine during the security routine used to authenticate the new code. Thus, the trusted machine, not the smart card, performs the security routine. Such a process requires that the smart card export proprietary security keys. Once exported, the smart card loses control over the keys, thereby creating a number of additional opportunities for hackers to breach the card""s security.
The present invention provides a system and method by which one or more applications may be securely installed on a smart card. Additionally, the present invention provides a system and method by which one or more applications may be securely de-installed from a smart card. The capabilities of a true operating system running on the smart card are used to facilitate the install and de-install operations.
In one aspect, the present invention allows a clear definition to be drawn between manufacture of the smart card and it""s programming. Thus, a method of manufacturing a smart card is provided, where the smart card comprises a microprocessor and a memory, the memory comprising ROM and read/write memory. The method comprises storing at least a portion of an operating system (OS) in ROM, storing at least a boot application in ROM, and following complete manufacture of the smart card, providing the smart card to an issuer without material data stored in read/write memory. The material data comprises either a file structure or a security key.
In another aspect, the present invention provides a method of initializing a smart card. Assuming the smart card comprises a microprocessor and a memory and the memory comprises a ROM and read/write memory, the ROM storing an operating system (OS) and an application, the method comprises; powering the smart card via a terminal, determining whether the smart card has ever previously been powered, and upon determining that the smart card has never previously been powered, performing an first-power initialization routine.
The first-power initialization routine comprises initializing the read/write memory, locating the application in ROM, and installing the application in read/write memory. The application may comprise a boot application allowing insertion of a new data object into read/write memory, and a call to a download manager in the OS. Following installation of the application in read/write memory, an initialization routine may be performed which comprises building a memory management record, and sending an Answer-To-Reset (ATR) signal to the terminal. The initialization routine might further comprise; determining whether a transaction record is present in memory, and upon determining that a transaction record is present in memory calling a transaction manager, and by operation of the transaction manager, clearing the transaction record.
Given the potential length of the first-power initialization routine and the initialization routine, before performing either the smart card may send a first portion of the ATR signal to the terminal, and wherein the step of sending the ATR signal to the terminal following the step of building the memory management record comprises sending a second portion of the ATR signal to the terminal.
In another aspect of the present invention, the ROM-based boot application is installed upon first-power initialization and used to download a new application data object which is ultimately converted to a new application. To accomplish this, the boot application will return a command table when installed, the commands in the table allowing for the download of the new application data object and calling of a download manager. When called the download manager will in turn call the new application data object. The new application data object will create a command table for the new application which is stored in read/write memory. Before calling the download manager, the boot application may perform a security verification routine on the new application data object.
In yet another aspect, the present invention provides a method of downloading a second application from a terminal into a smart card memory, the memory storing an operating system (OS) and a first application, the method comprising; calling the first application from the terminal, by operation of the first application, inserting a new application data object in memory, and converting the new application data object into the second application. Before converting the new application data object into the second application, the first application may verify the authenticity of the new application data object using a digital signature, for example.
Within this method, the step of converting the new application data object into the second application comprises; calling a download manager in the OS, calling the second application from the download manager, and generating a command table for the second application.
Command tables and other persistent data records within the context of the present invention may be stored and accessed in a file directory using an efficient data record structure using OS based file manager.
In still another aspect, the present invention provides a method of de-installing an application on a smart card, the smart card comprising a microprocessor and a memory, the memory storing an operating system (OS) and the application, the method comprising; deleting all data objects associated with the application, and deleting all data records associated with the application.
In a related aspect, step of deleting all data objects associated with the application, and deleting all data records associated with the application comprises; beginning with a 1st data object associated with the application and continuing through the Nth data object associated with the application, for each data object, deleting the data object by operation of the application, and calling the file manager, and by operation of the file manager, deleting the data record associated with the data object. Following deletion of the Nth data object and the Nth data record associated with the application, the method may thereafter delete the application data record from memory, and by operation of the memory manager reallocate memory space associated with the application as being available.